Developer CD Series 1993…ch: Other People's Memory/ADC Developer CD (1993-03) (''Other People's Memory'')_iso/Dev.CD Mar 93.iso/Development Platforms/CSMP Digests/csmp-v1-020.txt

Text File | 1992-11-18 | 50.7 KB | 1,373 lines | [TEXT/MPS ]

C.S.M.P. Digest             Tue, 17 Mar 92       Volume 1 : Issue 20

Today's Topics:

    What is system error #90?
    DA problem (6.07)
    How to turn off disk cacheing in System 7
    malloc in thinkC
    System Error 33
    Setting private CDEF values?
    Wanted, workaround to UpdateMovieResource() "feature"
    >>MAC ARCHIVE is being killed.. PLEASE HELP<<
    MPW Programming Guide
    Gunky 32K static (initialized) data segment barrier


The Comp.Sys.Mac.Programmer Digest is moderated by Michael A. Kelly.

These digests are available (by using FTP, account anonymous, your email
address as password) in the pub/mac/csmp-digest directory on ftp.cs.uoregon.
edu (try skinner.cs.uoregon.edu if that doesn't work).  This is also the home
of the comp.sys.mac.programmer Frequently Asked Questions list.

These digests are also available via email.  Just send a note saying that you
want to be on the digest mailing list to [e-mail], and you will
automatically receive each new digest as it is created.

The articles in these digests are taken directly from comp.sys.mac.programmer.
They are not edited; all articles included in this digest are in their original
posted form.  The only articles that are -not- included in these digests are
those which didn't receive any replies (except those that give information
rather than ask a question).  All replies to each article are concatenated
onto the original article in the order in which they were received.  Article
threads are not added to the digests until the last article added to the
thread is at least one month old (this is to ensure that the thread is dead
before adding it to the digests).

Send administrative mail to [e-mail].

-------------------------------------------------------

From: [e-mail] (Nigel Stanger)
Subject: What is system error #90?
Date: 11 Feb 92 21:49:56 GMT
Organization: University of Otago, Dunedin, New Zealand

I was trying to load an Excel file this morning. I was on an si
and was loading the file off a floppy. It would get as far as
2% loaded then CRASH! System error #90. I went and looked it up
in the System Errors list. IT'S NOT THERE?!

Yup, system error #90 is not documented in anything I've got
immediate access in (including IM1-6). What on earth is error
#90? Numbers 87-89 are "Could not load WDEF/CDEF/MDEF". Could 90
be LDEF? Help!

(BTW, this problem only seems to happen on this one particular
si, hopefully knowing what the error is might give me some handle
on figuring out the problem. Then again, maybe not :)

--
See ya
                                Nigel.
- --------------------------------------------------------------------
Nigel Stanger,                  Internet: [e-mail]
University of Otago,            Phone: [phone]
Dunedin, NEW ZEALAND.           Fax:   [phone]
Today's tang tongueler: try saying "Samuel Butler Yates" fast 3 times.



- -------------------------

From: [e-mail] (Pete Gontier)
Subject: What is system error #90?
Date: 12 Feb 92 02:42:15 GMT


 NS> From: [e-mail] (Nigel Stanger)

 NS> Yup, system error #90 is not documented in anything I've got

How about "Somebody passed garbage to _SysError"? :-)
 * Origin: EC Technology, Santa Barbara, CA (1:109/70.811)



- -------------------------

From: [e-mail] (Jerry Sy)
Subject:  What is system error #90?
Organization: Case Western Reserve University, Cleveland, OH (USA)
Date: Wed, 12 Feb 92 13:42:42 GMT


In a previous article, [e-mail] (Pete Gontier) says:

> NS> From: [e-mail] (Nigel Stanger)
>
> NS> Yup, system error #90 is not documented in anything I've got
>
>How about "Somebody passed garbage to _SysError"? :-)
> * Origin: EC Technology, Santa Barbara, CA (1:109/70.811)
>

Well, I guess you have not looked HARD enough.

Simply checking the Errors.h file of my think c compiler reveals that this
is a noFPU error.  You are running a software with FPU code on a machine
without an FPU !!  try using softFPU or some other FPU emulator.

jerry sy





- -------------------------

From: [e-mail] (Frank O'Connor)
Subject:  What is system error #90?
Date: 16 Feb 92 03:56:38 GMT
Organization: AUSOM - The Apple Users Society of Melbourne

PG
PG> NS> From: [e-mail] (Nigel Stanger)
PG
PG> NS> Yup, system error #90 is not documented in anything I've got
PG>How about "Somebody passed garbage to _SysError"? :-)

Nice one, Pete.

I've got System Error 90 down as the execution of an FPU instruction
when no FPU is installed. You might get around it by installing the
Software FPU init - which traps same and executes in software.

Regards,
--
- ----------------------------------------
Listen, someone is screaming in agony!
Fortunately I speak it fluently
- ----------------------------------------



- -------------------------

From: [e-mail] (Pete Gontier)
Subject:  What is system error #90?
Date: 14 Feb 92 04:51:19 GMT


 JS> From: [e-mail] (Jerry Sy)

 JS> Simply checking the Errors.h file of my think c compiler reveals that
 JS> this is a noFPU error.  You are running a software with FPU code on a
 JS> machine without an FPU !!  try using softFPU or some other FPU emulator.

Sonofabitch! I didn't know those were in there. Thanks for the tip.
 * Origin: EC Technology, Santa Barbara, CA (1:109/70.811)



---------------------------

From: [e-mail]
Subject: DA problem (6.07)
Date: 12 Feb 92 17:10:23 GMT
Organization: Brandon University, Brandon, Manitoba, Canada

I have a problem with a deskaccessory I have written (Think C 4). Does
somebody know what may be wrong considering the following symptom:
If I install the DA into 6.07 with F/DA Mover 3.8, then restart the Mac
everything works fine. If I use the same procedure but do not restart,
a system error (illegal instruction) occurs upon selecting the DA from
the menu. The DA menu has not yet appeared. (This is on an LC, but the crash
has also ben reported by other people (with unknown Mac and system 6.04
& 6.05). There is no problem with runing the DA from the Desktop under 7+).

Thank you for any suggestion.
- -----------------------------------------------------------------------------
Andreas Guelzow  Dept. of Mathematics & Comp. Sc. Brandon University MB Canada
[e-mail]



- -------------------------

From: [e-mail]
Subject:  DA problem (6.07)
Date: 13 Feb 92 14:54:52 GMT
Organization: Brandon University, Brandon, Manitoba, Canada

In article <[e-mail]>, I wrote:
> I have a problem with a deskaccessory I have written (Think C 4). Does
> somebody know what may be wrong considering the following symptom:
> If I install the DA into 6.07 with F/DA Mover 3.8,
or 4.1 on a Mac LC
> then restart the Mac
> everything works fine. If I use the same procedure but do not restart,
> a system error (illegal instruction) occurs upon selecting the DA from
> the menu.
While the DRVR resource has been loaded any of my code in the DCOD resource
has not been reached, in fact it hasn't even been loaded. (I am writing a
multi-segment DA.) The "illegal instruction" is not in any heap and decompiling
that part of memory shows that the instruction is in fact the second half of
one.
> The DA menu has not yet appeared. (This is on an LC, but the crash
> has also ben reported by other people (with unknown Mac and system 6.04
> & 6.05). There is no problem with runing the DA from the Desktop under 7+).
I also have no problem on my Mac Plus. On it I can't persuade the programme
to crash. This makes finding the bug very difficult.
>
> Thank you for any suggestion.
- -----------------------------------------------------------------------------
Andreas Guelzow  Dept. of Mathematics & Comp. Sc. Brandon University MB Canada
[e-mail]



---------------------------

From: [e-mail] (David Castell)
Subject: How to turn off disk cacheing in System 7
Date: 13 Feb 92 15:13:54 GMT
Organization: Computer Systems Group

In the past I have seen some people asking about turning off disk cacheing
under System 7.  I think I might have the answer.

In previous versions, to turn off disk cacheing you would turn off a bit
in the Parameter Ram.  This does not work under System 7.  However, there
is a low memory global called 'cacheCom' ($39c) which contains a bit called
'noRWIPbit' (bit 7).  The operating system routines that perform the cacheing
are '_vCacheRdIP' and '_vCacheWrIP'.  These routines check the 'noRWIPbit'
of CacheCom when deciding whether or not to perform the cacheing.  If the
bit is set, cacheing will not be performed.

If you want to have cacheing on in general, but don't want a particular
Read or Write call to be cached, set 'noCacheBit' (bit 5) in the ioPosMode
field of the Read or Write call.

NOTE: These two methods of manipulating cacheing are available in system 6
of the OS as well as system 7.  (and maybe even earlier versions, but I can't
verify this).

I hope this is of some help.

Dave Castell
Computer Systems Group



- -------------------------

From: Mike Wiese <[e-mail]>
Subject:  How to turn off disk cacheing in System 7
Organization: MIT
Date: Thu, 13 Feb 1992 19:55:40 GMT

>In the past I have seen some people asking about turning off disk
cacheing
>under System 7.  I think I might have the answer.
>
>In previous versions, to turn off disk cacheing you would turn off a bit
>in the Parameter Ram.  This does not work under System 7.  However, there
>is a low memory global called 'cacheCom' ($39c) which contains a bit
called
>'noRWIPbit' (bit 7).  The operating system routines that perform the
cacheing
>are '_vCacheRdIP' and '_vCacheWrIP'.  These routines check the
'noRWIPbit'
>of CacheCom when deciding whether or not to perform the cacheing.  If the
>bit is set, cacheing will not be performed.



---------------------------

From: [e-mail] (Christophe Dubreuil)
Subject: malloc in thinkC
Date: 14 Feb 92 09:48:57 GMT
Organization: CERT, CS Dpt. Toulouse, France


I got thinkC 4.0.5, I allready programmed in C
in a UNIX environnement, and I have been a
fervent Mac user.

But help !!!

Malloc allways return a NULL pointer in thinkC.
Am I missing something:

- not including the right libraries ?

- using malloc instead of another memory
  allocation fonction specific to the mac ?

Any help is welcome.


- ------------------------------------------------------------------------
Christophe Dubreuil,                   GIA DERI CERT ONERA, 2 av. E. Belin
[e-mail]           B.P. 4025, 31055 Toulouse Cedex,  France



- -------------------------

From: [e-mail] (Pai Hsiang Chou)
Subject:  malloc in thinkC
Organization: Computer Science & Engineering, U. of Washington, Seattle
Date: Fri, 14 Feb 92 11:29:19 GMT

In article <[e-mail]> [e-mail] (Christophe Dubreuil) writes:
>
>I got thinkC 4.0.5, I allready programmed in C
>in a UNIX environnement, and I have been a
>fervent Mac user.
>
>But help !!!
>
>Malloc allways return a NULL pointer in thinkC.

In THINK C, malloc takes a 16-bit argument.
This means you can allocate up to only 32K chunks at a time.
This is probably due to the fact that you can't index an array
that's bigger than 32K.

If you pass a longint (32-bit) argument, then chances are the
higher order 2 bytes are zero, so you got a NULL pointer.

>Am I missing something:
>
>- not including the right libraries ?

You might want to turn on "Require Prototypes" and include the
header files.  ANSI C Prototypes will take care of typecasting
some arguments like int/longint.


>- using malloc instead of another memory
>  allocation fonction specific to the mac ?

Or you could call the Mac Toolbox routines NewHandle() or
NewPtr().  They don't have the 32K restriction, but you
can't index more than 32K at a time; you can get around this
by computing pointers yourself.

Pai



- -------------------------

From: [e-mail] (Rich Siegel)
Subject:  malloc in thinkC
Date: 14 Feb 92 13:01:54 GMT
Organization: Symantec Language Products Group

In article <[e-mail]> [e-mail] (Pai Hsiang Chou) writes:
>>
>>But help !!!
>>
>>Malloc allways return a NULL pointer in thinkC.
>
>In THINK C, malloc takes a 16-bit argument.
>This means you can allocate up to only 32K chunks at a time.
>This is probably due to the fact that you can't index an array
>that's bigger than 32K.

    This is half correct. In THINK C 4.0, malloc() did indeed take
a 16-bit argument; however, it has nothing to do with array indexing
limitations - you can have arrays whose aggregate size is bigger than
32K, and you can index them just fine. They can't be statically declared
in THINK C 4.0, but that's beside the point.

    Furthermore, THINK C 4.0 includes a routine mlalloc(). (Note the "L".)
This routine takes a long as its argument. This is also beside the point.

    A common cause of "failure" in malloc() is failure to include
<storage.h>; any undeclared function defaults to a return-type of 'int',
and malloc() returns a 32-bit value, not a 16-bit value.

    THINK C 5.0 includes a set of libraries which are conformant with
the ANSI spec; as such, there is no mlalloc(), and malloc() itself takes
a size_t as its argument, which is a long. The C 5.0 libraries are, on the
whole, somewhat better defined and more reliable than previous versions.
Upgrading is recommended.

R.



--
- ---------------------------------------------------------------------
Rich Siegel                              Internet: [e-mail]
Senior Software Engineer                 Applelink: SIEGEL
Symantec Languages Group



- -------------------------

From: [e-mail]
Subject:  malloc in thinkC
Date: 14 Feb 92 19:46:32 GMT
Organization: Univ of Miami IR

In article <[e-mail]>, [e-mail] (Rich Siegel) writes:
> In article <[e-mail]> [e-mail] (Pai Hsiang Chou) writes:
>>>
>>>But help !!!
>>>
>>>Malloc allways return a NULL pointer in thinkC.
>>
>>In THINK C, malloc takes a 16-bit argument.
>>This means you can allocate up to only 32K chunks at a time.
>>This is probably due to the fact that you can't index an array
>>that's bigger than 32K.
>
>     This is half correct. In THINK C 4.0, malloc() did indeed take
> a 16-bit argument; however, it has nothing to do with array indexing
> limitations - you can have arrays whose aggregate size is bigger than
> 32K, and you can index them just fine. They can't be statically declared
> in THINK C 4.0, but that's beside the point.
>
>     Furthermore, THINK C 4.0 includes a routine mlalloc(). (Note the "L".)
> This routine takes a long as its argument. This is also beside the point.
>
>     A common cause of "failure" in malloc() is failure to include
> <storage.h>; any undeclared function defaults to a return-type of 'int',
> and malloc() returns a 32-bit value, not a 16-bit value.
>
>     THINK C 5.0 includes a set of libraries which are conformant with
> the ANSI spec; as such, there is no mlalloc(), and malloc() itself takes
> a size_t as its argument, which is a long. The C 5.0 libraries are, on the
> whole, somewhat better defined and more reliable than previous versions.
> Upgrading is recommended.

Well, in THINK C 5.0, you still have to include <stdlib.h> or you're liable
to be stuck with the same NULL problem. (This is documented in Think's  Std.
C Lib Reference). I was puzzled by why it occurs with blocks of 16K or
thereabouts though. It works fine for anything smaller (because it is
allocated by THINK C from its free list), and larger blocks are handled by
calling NewPtr(). It's just this range of block sizes of about 16K that
causes it to fail. After including <stdlib.h>, it works properly.

Does anyone know why?

T.C. Wan
Grad Student,
Univ of Miami, FL

>
> R.
>
>
>
> --
> -----------------------------------------------------------------------
> Rich Siegel                              Internet: [e-mail]
> Senior Software Engineer                 Applelink: SIEGEL
> Symantec Languages Group



- -------------------------

From: [e-mail] (David Swofford )
Subject:  malloc in thinkC
Organization: University of Illinois at Urbana
Date: Fri, 14 Feb 1992 23:23:39 GMT

[e-mail] (Rich Siegel) writes:

>    THINK C 5.0 includes a set of libraries which are conformant with
>the ANSI spec; as such, there is no mlalloc(), and malloc() itself takes
>a size_t as its argument, which is a long. The C 5.0 libraries are, on the
>whole, somewhat better defined and more reliable than previous versions.
>Upgrading is recommended.

On the whole, I completely agree with this statement, but one aspect of the
new malloc scheme really bothers me.  In THINK C 5 library, memory requests
of less than 15K bytes are filled from 15K "zones" with new zones being
allocated as necessary.  The obvious benefits of this strategy are that
far fewer calls to the Mac Memory Manager routines are necessary, and
there is much less memory overhead for block headers (they use a clever
system that requires only 6 bytes of header for each block (two bytes
for the size, 4 bytes for either a pointer or a flag indicating that the
block has been freed or was >15K and therefore allocated by NewPtr)).

The problem is that if all of the blocks within a 15K zone are freed, the
zone itself is not returned to the Memory Manager; it just sits there
plugging up memory (Rich, please correct me if I'm wrong, but this was
my experience).  This proved deadly to one part of my application.  I
allocate a linked list of large (say, 12K) structures by successive calls
to malloc.  This is all done at one time following a certain action by
the user.  Suppose that after allocating 18 of 20 of these structures, the
Mac runs out of memory.  No problem, just run back through the list, free
all the blocks allocated so far, and tell the user there's not enough
memory to do what s/he wants.  But when the THINK C free is called, it
just marks the block as available for filling future requests.  This
means that I've now got 18 empty 15K nonrelocatable blocks and no free
memory for any other purpose (e.g., handles for Mac interface stuff).
If the user decides to change the request so that only half as many of
these list items are needed, I can recover half the memory, but there's
STILL no memory for requests outside of the malloc/free realm.  In my
case, the problem was severe enough that I had to resort to writing my
own versions of malloc and free that just called NewPtr and DisposPtr
forgoing all of the advantages of THINK's new system.

The obvious solution would be to modify the library's version of free
so that after every call to free, it checked to see whether there were
any blocks left in the zone, and if not, freed the entire zone.  I could
do this myself, but I'd rather THINK did it.

PLEASE NOTE:  This application runs on everything from Macs to IBM PCs
to Unix workstations to Cray Y/MPs.  For portability, I really want to
use malloc/free.  The usual suggestions that I should be using
relocatable blocks rather than malloc/free are not welcome.
--
David L. Swofford                 Phone:    [phone]
Illinois Natural History Survey   FAX:      [phone]
607 E. Peabody Drive              BITNET:   DAVESWOF@UIUCVMD
Champaign, Illinois 61820 USA     Internet: [e-mail]



- -------------------------

From: [e-mail] (Michael Kahl)
Subject:  malloc in thinkC
Date: 15 Feb 92 03:31:30 GMT
Organization: Enginuity Inc.

In article <[e-mail]> [e-mail] (Rich Siegel) writes:
>In article <[e-mail]> [e-mail] (Pai Hsiang Chou) writes:
>>>
>>>But help !!!
>>>
>>>Malloc allways return a NULL pointer in thinkC.
>>
>>In THINK C, malloc takes a 16-bit argument.
>>This means you can allocate up to only 32K chunks at a time.

Not true.  malloc takes a size_t, which is an unsigned long.

>>This is probably due to the fact that you can't index an array
>>that's bigger than 32K.

Also not true.  You can't declare an array that big, but a dynamically allocated
array has no such limit.

>    This is half correct. In THINK C 4.0, malloc() did indeed take
>a 16-bit argument; however, it has nothing to do with array indexing
>limitations - you can have arrays whose aggregate size is bigger than
>32K, and you can index them just fine. They can't be statically declared
>in THINK C 4.0, but that's beside the point.

This is half correct. :-)  Large (i.e. >32K) arrays can be indexed though not
statically declared; but the argument to malloc is a 32-bit int, not a 16-bit
int.

>    Furthermore, THINK C 4.0 includes a routine mlalloc(). (Note the "L".)
>This routine takes a long as its argument. This is also beside the point.

No.  I believe that version 3.0 had mlalloc (or clalloc), but with the advent
of the ANSI libraries in 4.0, it was dropped.

>    A common cause of "failure" in malloc() is failure to include
><storage.h>; any undeclared function defaults to a return-type of 'int',
>and malloc() returns a 32-bit value, not a 16-bit value.

Storage.h was present in old versions, but disappeared in 4.0.  It's true that
it is important to include <stdlib.h> when using malloc, in order to get the
argument and return types declared properly.

>    THINK C 5.0 includes a set of libraries which are conformant with
>the ANSI spec; as such, there is no mlalloc(), and malloc() itself takes
>a size_t as its argument, which is a long. The C 5.0 libraries are, on the
>whole, somewhat better defined and more reliable than previous versions.

True, but this change was introduced in 4.0.

>Upgrading [to 5.0] is recommended.

Also true, but not because of the standard libraries, which did not change
much.

--
Michael Kahl, Software Architect, Enginuity Inc.
[e-mail]  -or-  [e-mail]
Disclaimer:  Whoa!  Did I say THAT??!



- -------------------------

From: [e-mail] (Phil Shapiro)
Subject:  malloc in thinkC
Organization: Symantec Corp.
Date: Sun, 16 Feb 1992 17:12:28 GMT

>>>>> On 14 Feb 92 23:23:39 GMT, [e-mail] (David Swofford ) said:

 > (they use a clever system that requires only 6 bytes of header for
 > each block (two bytes for the size, 4 bytes for either a pointer or
 > a flag indicating that the block has been freed or was >15K and
 > therefore allocated by NewPtr)).

Actually the overhead is only 2 bytes per block (3 if you're
malloc'ing an odd sized block). The zones have an overhead of 8 bytes.

 > The problem is that if all of the blocks within a 15K zone are
 > freed, the zone itself is not returned to the Memory Manager; it
 > just sits there plugging up memory

This is the way that THINK C's malloc() works. This is part of the
design, and it isn't considered to be a bug.

 > The obvious solution would be to modify the library's version of
 > free so that after every call to free, it checked to see whether
 > there were any blocks left in the zone, and if not, freed the
 > entire zone.  I could do this myself, but I'd rather THINK did it.

It's possible that this feature would be added in the future, but we
get very few complaints about its behavior -- if you really want it,
I'd recommend adding in the support yourself. Remember that alloc()
keeps a linked list of zones, so you'd have to patch up the list if
you freed a zone.

One side note: for those that were confused by Rich's remarks about
mlalloc(), 16 bit arguments and <storage.h>, he was referring to the
libraries in C 3.0, not 4.0 (feel old, Rich? :-).

    -phil
--
   Phil Shapiro                           Technical Support Analyst
   Language Products Group                     Symantec Corporation
        Internet: [e-mail]



---------------------------

From: [e-mail] (Daniel L. McDonald)
Subject: System Error 33
Date: 14 Feb 92 16:53:41 GMT
Organization: U of Arizona CS Dept, Tucson

I'm the administrator for a room full of Mac SE's.  They are all appletalked
together.  The total node count for this subnet is 34

    1 FastPath link to the campus internet
    1 Mac IIfx file server
    32 SE's

THe workstations, especially at the end of the chain will bomb with system
error 33.  Inside Mac #5 has it labelled as "ZcbFreeNeg" which means ZcbFree
is negative.  I can't find what ZcbFree is.  Is it an Appletalk system value?
Is the error resulting from too large a subnet?  That's my guess, but I'd like
to verify it with you people.

I'm posting this to two newsgroups, and reading comp.sys.mac.programmer.
Either mail to me, or post to comp.sys.mac.programmer.  Thanks!

+------------------+----------------------------------------------------------+
| Dan McDonald     | Internet: [e-mail]  AT&Tnet: [phone] |
| Univ. of Arizona +----------------------------+ UUCP:..!uunet!arizona!danmcd|
| Computer Science | "I was lined up for glory, +-----------------------------+
| 1st year Grad.   |  but the tickets sold out in advance" - Rush (N. Peart)  |
+------------------+----------------------------------------------------------+



- -------------------------

From: [e-mail] (Jamie R. McCarthy)
Subject:  System Error 33
Organization: Kalamazoo College
Date: Sun, 16 Feb 1992 16:55:38 GMT

[e-mail] (Daniel L. McDonald) writes:
>I'm the administrator for a room full of Mac SE's.  They are all appletalked
>together.
>
>THe workstations, especially at the end of the chain will bomb with system
>error 33.  Inside Mac #5 has it labelled as "ZcbFreeNeg" which means ZcbFree
>is negative.  I can't find what ZcbFree is.

Error 33 means your program was naughty:  it wrote someplace it wasn't
supposed to, probably past the end of a chunk of memory.

The error occurs when the memory manager gets a request to do something,
and in the course of setting up to do it, notices that the number of
free blocks in the heap is _negative_.  This of course should never
happen, and is only possible when its data structures get trashed.

It (probably) has nothing to do with the network situation, and
everything to do with the software you're running at the time.
--
 Jamie McCarthy     Internet: [e-mail]     AppleLink: j.mccarthy
 Kzoo randomly kills all my mail;  if I don't acknowledge, try resending.



---------------------------

From: [e-mail] (Kenneth Knight)
Subject: Setting private CDEF values?
Date: 11 Feb 92 23:29:36 GMT
Organization: Instructional Technology Laboratory, University of Michigan

I am creating a costum control for a project of mine. The costom control acts
like the controls that manipulate the memory or clock settings that you find
in Memory or General Control Panels. I want to give this control a good deal
of flexibility and therefore I want to provide options (in a private data
structure referenced via the cntlData Handle in the ControlRecord) for
changing the interval that values change by, and options for controlling how
fast the value changes (an acceleration of sorts). I have hard-coded some
default values for these extra options, but I want to allow for the values to
be modified if a resource of some type (e.g. 'arow') with the same ID as the
CNTL resource (and , of course, the CNTL includes the information that points
to the costum CDEF) that if found while the control is being set up will
substitute the values withint that resource for the hard-coded ones already
present. It makes sense to me to do all this work during the 'initCntl'
message that is sent to the CDEF, but I can't figure out how to do this. Can
anyone point me in the right direction, tell me what to do? Thanks....

  ** Ken **


I am me and only me and speak just for me.



- -------------------------

From: [e-mail] (Robert H Earhart)
Subject:  Setting private CDEF values?
Date: 16 Feb 92 20:07:21 GMT
Organization: Freshman, MCS general, Carnegie Mellon, Pittsburgh, PA


  Have you considered using a preferences file? They're REALLY easy to
manage under System Seven... and not as gross as modifying one's one
resources, or the system file.

  -Rob



---------------------------

Subject: Wanted, workaround to UpdateMovieResource() "feature"
From: [e-mail] (USENET News System)
Date: Sun, 16 Feb 1992 20:59:33 GMT
Organization: School of Maths & Info. Sci., Massey University, Palmerston North, NZ


The QT routine UpdateMovieResource() sets a files shared bit for some
unknown reason. If you look at your Scrapbook file after you've pasted
a movie in you'll see it now has it shared bit set. My problem is I
was trying to use the "Gallery" application of the QT CD, which is
just a version of scrapbook compiled as an app and which stores the
scraps within itself.  It works fine as long as you don't paste in
movies, once you do then the next time you launch the app the Finder
pens the resource fork red only as its marked shared - which means
pasting is no longer possible :-(. Anybody know WHY the bit is being set?
Anybody have a fix?

Thanks in advance,

        Nigel

--
- -
Dr Nigel Perry                    Email: [e-mail]
Department of Computer Science    Tel: [phone] ext 8900
Massey University                 Fax: [phone]
Palmerston North
New Zealand



---------------------------

From: [e-mail] (Mike Dautermann)
Subject: >>MAC ARCHIVE is being killed.. PLEASE HELP<<
Date: 14 Feb 92 06:45:52 GMT
Organization: Archive Project, University of Mediocre

Dear mac-archive-user....

I have some very very disturbing and shocking (at least for me) news
to relay to you....

Due to budget constraints at the U-M Information Technology Division,
a tenative decision has been made to cut and cease support of the largely
volunteer archive service (i.e. mac.archive.umich.edu, msdos.archive.umich.edu,
next.archive.umich.edu, linguistics.archive, atari, etc.).

Here is a copy of the message I received about a half hour ago
from my supervisor on the project:

- ----

Message-Id: <[e-mail]>
To: [e-mail]
Subject: Death of the Archives?
Date: Thu, 13 Feb 92 23:48:01 -0500
From: "Fred Swartz" <[e-mail]>


                           ... ...I don't know exactly how this will
affect the 0.25 part of Allan and Mike that RS pays for, perhaps CSS
and CITI will pick it up.  I'll let you know when/if I find out.

When I talked to Mike Clark (my manager in Research Systems) about
continuing the archives on volunteer power (as it largely runs right
now), he was very negative on the idea, but failed to supply a
convincing argument for abandoning it.  I'm stunned and upset.
The Archives have managed very well on volunteer effort up til now and
it seems to me that something else is going on other than a genuine
concern for serving the users.

I don't know what this means for the Archives, although they aren't
going to be turned off tomorrow.  I'll let you know whatever I find out
as soon as I can.

  -- Fred

- ---

I talked on the phone with Fred and we both agree that this decision
seems very unfair to both the students/faculty who use the archives
here at the University of Michigan, and you... the users on the
Internet, Bitnet, UUCP, etc.

To me, it doesn't make much sense to cut off support for the archives.
Both I and Allan make around $70 a week working on the archives (I work
on the Mac side, he works on the msdos side).. the rest of the time
we spend is voluntary, like the twenty or so other people who add/keep
up the archives here.  The archives are probably one of the most popular
and beneficial services that ITD offers.  There may be other ways to trim
the budget, but cutting off something that costs nearly nothing
to begin with doesn't seem very wise.

Please help us out.  E-mail in support of our archives can be sent
to [e-mail].  We don't want to flood the
senior managers' mailboxes, and we're still thinking about what we
can do to save our archives.  Comments can be sent
to us at "[e-mail]".  To address the entire
archive group, you may send e-mail to "[e-mail]".
Also, please let your other computer friends and acquaintances know what is
going on.  We need as many letters/e-mail notes as possible in order
to emphasize just how much the archives mean to people.

Thanks....

[e-mail]

p.s. I apologize for having to crosspost this to so many newsgroups.
(I'm also probably risking getting fired, as well).  I just wanted
you to be aware of what is happening and ask for you to consider about
sending a note of support for us...

--
- ---------------------------------------------------------------
Mike Dautermann - U-M Ann Arbor, Dearborn and the World
Mike @ ccs.itd.umich.edu = [e-mail] = [e-mail]
= [e-mail] --> that's MISTER archive to you.....



---------------------------

From: [e-mail] (Bruce Cheng)
Subject: MPW Programming Guide
Date: 21 Jan 92 14:24:34 GMT
Organization: University of Rochester, Department of Electrical Engineering


    Is there any good suggestion for Programming Guide for MPW? I curently only
    have the reference manual that comes with the package.

    The MPW Programmer's Reference I and II.
    Same for MPW C, I only have the Programmer's Reference.

    Or basically any material that can help me to shorten my learning curve
    on Mac programming ...


thanks a MEG!
Bruce
--
+-----------------------------------------+------------------------------------+
| Home: 716-271-0960(voice/data/fax)      |Usnet: [e-mail]       |
| Work: 716-427-6227                  |XNS: [e-mail] |
| Address: 1559 Elmwood Avenue Apt 8      |Uucp: uunet!rochester!ur-val!cheng  |



- -------------------------

From: [e-mail] (Keith Rollin)
Subject:  MPW Programming Guide
Date: 28 Jan 92 23:08:14 GMT
Organization: Apple Computer Inc., Cupertino, CA

In article <[e-mail]> [e-mail] (Bruce Cheng) writes:
>
>    Is there any good suggestion for Programming Guide for MPW? I curently only
>    have the reference manual that comes with the package.
>
>    The MPW Programmer's Reference I and II.
>    Same for MPW C, I only have the Programmer's Reference.
>
>    Or basically any material that can help me to shorten my learning curve
>    on Mac programming ...

I know of only two How To Use MPW books other than the reference
manuals that come with it. The first is an Ages Old book by Joel West
(I don't remember the name or publisher).  This book covers MPW 2.0,
and may not be of much use. More recently is "Programmer's Guide to MPW"
(right...so I don't accidentally think the book is appropriate for my
mother), by Mark Andrews, published as part of the Macintosh Inside
Out series by Addison Wesley Crusher. This book is marked as Volume 1,
so I guess more volumes are forthcoming (I heard a rumor that a Volume
2 is being worked on by Neil Rhodes, who used to (or still does) work
with Joel West).

I've never read either of these books, so I don't know if they're any
good.

--
- ----------------------------------------------------------------------------
Keith Rollin           ---            <Taligent .signature under construction>
Disclaimer: Pretty soon, I really _won't_ be speaking for Apple...



- -------------------------

From: [e-mail] (Jess M Holle)
Subject:  MPW Programming Guide
Date: 29 Jan 92 04:11:47 GMT
Organization: Purdue University Engineering Computer Network

Additionally, though it does not cover MPW in general, but rather just
some facets of it and its use in programming various things is:

On Macintosh Programming: Advanced Techiques
by Daniel K. Allen
Addison/Wesley

This book may be of some help.

Jess Holle



- -------------------------

From: [e-mail] (Keith Rollin)
Subject:  MPW Programming Guide
Date: 28 Jan 92 23:08:14 GMT
Organization: Apple Computer Inc., Cupertino, CA

In article <[e-mail]> [e-mail] (Bruce Cheng) writes:
>
>    Is there any good suggestion for Programming Guide for MPW? I curently only
>    have the reference manual that comes with the package.
>
>    The MPW Programmer's Reference I and II.
>    Same for MPW C, I only have the Programmer's Reference.
>
>    Or basically any material that can help me to shorten my learning curve
>    on Mac programming ...

I know of only two How To Use MPW books other than the reference
manuals that come with it. The first is an Ages Old book by Joel West
(I don't remember the name or publisher).  This book covers MPW 2.0,
and may not be of much use. More recently is "Programmer's Guide to MPW"
(right...so I don't accidentally think the book is appropriate for my
mother), by Mark Andrews, published as part of the Macintosh Inside
Out series by Addison Wesley Crusher. This book is marked as Volume 1,
so I guess more volumes are forthcoming (I heard a rumor that a Volume
2 is being worked on by Neil Rhodes, who used to (or still does) work
with Joel West).

I've never read either of these books, so I don't know if they're any
good.

--
- ----------------------------------------------------------------------------
Keith Rollin           ---            <Taligent .signature under construction>
Disclaimer: Pretty soon, I really _won't_ be speaking for Apple...



---------------------------

From: [e-mail] (Jerry Frain)
Subject: Gunky 32K static (initialized) data segment barrier
Date: 22 Jan 92 05:29:08 GMT
Organization: Kansas State University, Dept. of Computing and Information Sciences

The other day, I decided to attempt to port gas (GNU assembler) to my
Mac, compiling it with THINK C 4.x.  (I was REAL bored, mind you.)

All of the files compiled with relative ease, except the file that
includes the description of the 68k assembly language.  The problem is
that the static array that contains the data for all of the
instructions is by itself larger than 32K.

A friend of mine suggested writing a program to read the information
from a file into dynamic memory, then save the result as a resource.

The idea at first appeared absurd.  Now that I think about it, it's
not too bad, and I'm fresh out of alternatives.  If you like the above
idea, I'd like to hear how you would save it as a resource.

My only other idea is to cut out (at least temporarily) the MMU (and
probably FPU) instructions, and see if that trims it down enough to
compile.

Obviously, I'm not the first person to be in this situation.  Anyone
else out there care to share other ideas for breaking the 32K static
data segment barrier?

  --Jerry

--
- ----------------------------------------------------------------------------
Jerry Frain, Systems Programmer         |  "Back off man, I'm a scientist."
Kansas State University                 |  [e-mail]
Department of Computer & Info Sciences  |  ...!rutgers!depot!frain



- -------------------------

From: [e-mail] (Jamie R. McCarthy)
Subject:  Gunky 32K static (initialized) data segment barrier
Date: 22 Jan 92 14:32:00 GMT
Organization: Kalamazoo College

[e-mail] (Jerry Frain) writes:
>
>All of the files compiled with relative ease, except the file that
>includes the description of the 68k assembly language.  The problem is
>that the static array that contains the data for all of the
>instructions is by itself larger than 32K.
>
>A friend of mine suggested writing a program to read the information
>from a file into dynamic memory, then save the result as a resource.
>

The easiest way would be to upgrade to Think C 5, which supports
unlimited globals.

The _cheapest_ way would probably be to do as your friend suggested.
Here's the code I used.


Point thePlace;
Str255 thePrompt = "\pHi!";
macSFReply theSFReply;
short myDFRefNum;
Handle myBigHndl;
OSErr theOSErr;

SetPt(&thePlace, 30, 50);
SFGetFile(thePlace, thePrompt, (ProcPtr) NULL, -1, (SFTypeList*) NULL,
    (ProcPtr) NULL, &theSFReply);
if (! theSFReply.good)     /* if the user clicked "Cancel" */
    return; /* forget the whole thing */
theOSErr = FSOpen(theSFReply.fName, theSFReply.vRefNum,
    &myDFRefNum);
myBigHndl = NewHandle(200000L);
HLock(myBigHndl);
myCount = 190000L;
theOSErr = FSRead(myDFRefNum, &myCount, *myBigHndl);
SetHandleSize(myBigHndl, myCount);
AddResource(myBigHndl, 'DATA', 128, theSFReply.fName);
WriteResource(myBigHndl);


Since it's a one-time, quick-n-dirty solution, you don't have to worry
about creating a resource file, opening it, and closing it.  Just run
the project from Think C, and the AddResource and WriteResource will put
the new resource into the .project.rsrc file.  Then transfer that
resource over to the gas.project.rsrc file, and you're off and
running...
--
 Jamie McCarthy     Internet: [e-mail]     AppleLink: j.mccarthy



- -------------------------

From: [e-mail] (Eric W. Sink)
Subject:  Gunky 32K static (initialized) data segment barrier
Date: 22 Jan 92 15:45:23 GMT
Organization: University of Illinois at Urbana-Champaign

In <[e-mail]> [e-mail] (Jerry Frain) writes:

>Obviously, I'm not the first person to be in this situation.  Anyone
>else out there care to share other ideas for breaking the 32K static
>data segment barrier?

Yes, use Think C 5.0.

--
Eric W. Sink,  Spatial Analysis and Systems Team
USACERL, P.O. Box 9005, Champaign, IL 61826-9005
1-800-USA-CERL x449,   [e-mail]



- -------------------------

From: [e-mail] (Russell Street)
Subject:  Gunky 32K static (initialized) data segment barrier
Date: 22 Jan 92 20:41:14 GMT
Organization: University of Auckland, New Zealand.

[e-mail] (Jerry Frain) writes:

...

>Obviously, I'm not the first person to be in this situation.  Anyone
>else out there care to share other ideas for breaking the 32K static
>data segment barrier?

Get Think C 5 and turn on Far Code/Far Data.  Too easy?

If the problem is large arrays you can also do this:

Break the offending array declerations up so that they are under 32K each
and then write a special program to save these declerations into
resources (or the data fork of a file).

Then the initialization routines can NewPtr some large blocks,
GetResource these resources and copy them over to the blocks or
load the data in from the files.

Because of arrays and pointers are practically identical only
minor hitting will be required to get the declerations straight.

This does take a bit of effort, but it works succesfully.

Hope this helps someone...
- -----------------------------------------------------
And with that remark, folks, the case of the Crown vs
Russell Street ([e-mail]) was proven.



- -------------------------

From: [e-mail] (Rich Siegel)
Subject:  Gunky 32K static (initialized) data segment barrier
Date: 22 Jan 92 07:18:03 GMT
Organization: Symantec Language Products Group

In article <[e-mail]> [e-mail] (Jerry Frain) writes:
>The other day, I decided to attempt to port gas (GNU assembler) to my
>Mac, compiling it with THINK C 4.x.  (I was REAL bored, mind you.)
>
>All of the files compiled with relative ease, except the file that
>includes the description of the 68k assembly language.  The problem is
>that the static array that contains the data for all of the
>instructions is by itself larger than 32K.
>
>A friend of mine suggested writing a program to read the information
>from a file into dynamic memory, then save the result as a resource.
>
>The idea at first appeared absurd.  Now that I think about it, it's
>not too bad, and I'm fresh out of alternatives.  If you like the above
>idea, I'd like to hear how you would save it as a resource.
>
>My only other idea is to cut out (at least temporarily) the MMU (and
>probably FPU) instructions, and see if that trims it down enough to
>compile.

    Upgrade to THINK C 5.0. It supports FAR CODE and FAR DATA; the former
gives you up to 256K jump tables; the former gives you data space limited only
by available memory.

R.
--
- ---------------------------------------------------------------------
Rich Siegel                              Internet: [e-mail]
Senior Software Engineer                 Applelink: SIEGEL
Symantec Languages Group



- -------------------------

From: [e-mail] (Matthew T. Russotto)
Subject:  Gunky 32K static (initialized) data segment barrier
Date: 22 Jan 92 21:15:59 GMT
Organization: College of Engineering, Maryversity of Uniland, College Park

In article <[e-mail]> [e-mail] (Jerry Frain) writes:
>The other day, I decided to attempt to port gas (GNU assembler) to my
>Mac, compiling it with THINK C 4.x.  (I was REAL bored, mind you.)
>
>All of the files compiled with relative ease, except the file that
>includes the description of the 68k assembly language.  The problem is
>that the static array that contains the data for all of the
>instructions is by itself larger than 32K.
>
>A friend of mine suggested writing a program to read the information
>from a file into dynamic memory, then save the result as a resource.
>
>The idea at first appeared absurd.  Now that I think about it, it's
>not too bad, and I'm fresh out of alternatives.  If you like the above
>idea, I'd like to hear how you would save it as a resource.

Presumably this array is something like

struct foo {
  int bar
  char baz[42];
  int etc;
}

struct foo verybig[20] = {foo, bar, baz}

If so, I'd store it in the form it would appear in memory, so you can just
load it into the dynamic array:
MyHandle = GetResource(foo, 'foo ');
HLock(MyHandle);
verybig = *foo;

and be done with it.  Is there some
variable-length thing that might interfere.

>Obviously, I'm not the first person to be in this situation.  Anyone
>else out there care to share other ideas for breaking the 32K static
>data segment barrier?

MPW 3.2?  I think THINK 5.0 can do it too, but I haven't gotten to my copy
yet :-(

--
Matthew T. Russotto    [e-mail]    [e-mail]
Your superior intellect is no match for our puny weapons! -- The Simpsons
Just say NO to police searches and seizures.  Make them use force.
(not responsible for bodily harm resulting from following above advice)



- -------------------------

From: [e-mail] (Keith Rollin)
Subject:  Gunky 32K static (initialized) data segment barrier
Date: 28 Jan 92 23:20:27 GMT
Organization: Apple Computer Inc., Cupertino, CA

In article <[e-mail]> [e-mail] (Jerry Frain) writes:
>The other day, I decided to attempt to port gas (GNU assembler) to my
>Mac, compiling it with THINK C 4.x.  (I was REAL bored, mind you.)
>
>All of the files compiled with relative ease, except the file that
>includes the description of the 68k assembly language.  The problem is
>that the static array that contains the data for all of the
>instructions is by itself larger than 32K.
>
>A friend of mine suggested writing a program to read the information
>from a file into dynamic memory, then save the result as a resource.
>
>The idea at first appeared absurd.  Now that I think about it, it's
>not too bad, and I'm fresh out of alternatives.  If you like the above
>idea, I'd like to hear how you would save it as a resource.
>
>My only other idea is to cut out (at least temporarily) the MMU (and
>probably FPU) instructions, and see if that trims it down enough to
>compile.
>
>Obviously, I'm not the first person to be in this situation.  Anyone
>else out there care to share other ideas for breaking the 32K static
>data segment barrier?

As most readers of this group know, Stan Shebs here at Apple has ported
GNU C to work under MPW. Over the X-Mas break, I was playing around
with it, and noticed that it had over 100K of global variables. Stan
was able to compile these because he used the -m option with the
compiler and linker. However, this generates larger and less efficient
code. So I decided to take the approach you suggested above, and moved
a lot of static data into resources. I wrote a little MPW tool that
searched for about a dozen pre-designated tables (which I had
identified as being global variable hogs from the link map). The tool
then turned the C source for the tables into Rez source (the two
syntaxes are very similar). Next, I added some code at the start of the
GNU C compiler to read in these resources, lock them down, and
initialize some pointers to them. Since arrays and pointers in C are
tightly coupled, modifying the rest of the GNU C source to use the
pointers instead of accessing a global array was pretty simple.

--
- ----------------------------------------------------------------------------
Keith Rollin           ---            <Taligent .signature under construction>
Disclaimer: Pretty soon, I really _won't_ be speaking for Apple...



- -------------------------

From: [e-mail] (Keith Rollin)
Subject:  Gunky 32K static (initialized) data segment barrier
Date: 28 Jan 92 23:20:27 GMT
Organization: Apple Computer Inc., Cupertino, CA

In article <[e-mail]> [e-mail] (Jerry Frain) writes:
>The other day, I decided to attempt to port gas (GNU assembler) to my
>Mac, compiling it with THINK C 4.x.  (I was REAL bored, mind you.)
>
>All of the files compiled with relative ease, except the file that
>includes the description of the 68k assembly language.  The problem is
>that the static array that contains the data for all of the
>instructions is by itself larger than 32K.
>
>A friend of mine suggested writing a program to read the information
>from a file into dynamic memory, then save the result as a resource.
>
>The idea at first appeared absurd.  Now that I think about it, it's
>not too bad, and I'm fresh out of alternatives.  If you like the above
>idea, I'd like to hear how you would save it as a resource.
>
>My only other idea is to cut out (at least temporarily) the MMU (and
>probably FPU) instructions, and see if that trims it down enough to
>compile.
>
>Obviously, I'm not the first person to be in this situation.  Anyone
>else out there care to share other ideas for breaking the 32K static
>data segment barrier?

As most readers of this group know, Stan Shebs here at Apple has ported
GNU C to work under MPW. Over the X-Mas break, I was playing around
with it, and noticed that it had over 100K of global variables. Stan
was able to compile these because he used the -m option with the
compiler and linker. However, this generates larger and less efficient
code. So I decided to take the approach you suggested above, and moved
a lot of static data into resources. I wrote a little MPW tool that
searched for about a dozen pre-designated tables (which I had
identified as being global variable hogs from the link map). The tool
then turned the C source for the tables into Rez source (the two
syntaxes are very similar). Next, I added some code at the start of the
GNU C compiler to read in these resources, lock them down, and
initialize some pointers to them. Since arrays and pointers in C are
tightly coupled, modifying the rest of the GNU C source to use the
pointers instead of accessing a global array was pretty simple.

--
- ----------------------------------------------------------------------------
Keith Rollin           ---            <Taligent .signature under construction>
Disclaimer: Pretty soon, I really _won't_ be speaking for Apple...



---------------------------

End of C.S.M.P. Digest
**********************